Subject: APPN item 8265,8266

From: [email-masked]
Date: Fri, 28 Jul 95 08:25:43 EDT

Mike,

I don't think archaeologists could decipher what our notes were beginning
to look like, so I took the liberty of cleaning up the flags and indentations
a bit, and to focus only on open points.  If I missed an important point,
please bring it to our attention.  So....

Regarding your last comments on 8265:

1)  Scenario about duplicate node that is a VRN in which no NNs are connected
    to it, yet ENs supply TGs to this VRN on Locates to their respective NN
    servers.

OK.....but this requires all ENs on that connection network presumably to have
another link connecting them to an APPN network.  Otherwise the ENs could never
find the MAC/SAP @ of any of the other ENs.  Certainly possible, but kinda      strange.

I agree with you that in this scenario, it is possible for an NN server to
build a bad route, thinking that an EN is connected to the real NN duplicate,
when in fact the EN is connected to a VRN instead.  If this problem is
considered important enough to be worth solving, then I think there should be
a separate solution to address it.

8265 was created to address the problem of the VRN info. being destroyed when
another NN by the same name comes along and zaps it.  In your case, the VRN
information doesn't get destroyed because none of the NNs ever learn about it.

2)  Concern that a duplicate VRN may be caused through configuration change,
    via TG_UPDATE, yet 8265 does not address this problem.

Yes, a duplicate can be created this way.
The intent of the item was to check for duplicates whenever updating the
node record in the TDB, but glancing through the change pages, this check
is only described in the PROCESS_INPUT_TDU section.  Thanks for pointing this
out, Mike.  I'll change the documentation.

3)  Concern about whether a VRN and NN having the same CP name is a
    configuration error.

Your concern (ME:)
ME:From a user's viewpoint, he is not giving two nodes the same name.  He is
ME:giving a connection network and a node the same name.  I've not found a
ME:reference anywhere in the APPN Architecture Reference saying that connection
ME:network names occupy the same name-space as CP and LU names.  Much of the
ME:product documentation I've looked at is similarly vague about this
ME:restriction.  We just don't agree that this is
ME:a 'dumb' user error (we've even seen engineers at an Interop show configure
ME:a network this way).

A connection network always has a node associated with it, called a virtual
routing node (VRN).  A VRN and a real NN, in both physical terms and in logical
terms, are different nodes.  Our architecture states that all unique
(different) nodes must have different CP names.  OK, it's easy for users to
misinterpret how
to configure such nodes.  Maybe we need to provide better documentation on
VRNs, but we certainly don't want them to make the mistake you describe.
'Nuff said.

Other points you made:
ME:No.  When a node connected to VRN A receives a TDU for the TG from VRN A to
ME:itself, it should then broadcast a TDU correcting that information (since it
ME:owns that TG).  A TDU war occurs (which may be detected if someone has
ME:implemented the TDU war architecture update, or may continue unabated).

A TDU war shouldn't occur, because the node you are talking about does not
own that record.  The node owning that record is the node entry under which
that TG record is stored.  In your example, it is the VRN itself.  Since the
VRN never issues correcting TDUs (it's not real), a war should never occur,
regardless of whether down-level or up-level nodes exist in the network.

It is for this reason that we opened a new item to address this problem.  We
already have a solution (6308) that detects and stops TDU wars, but because
this problem never results in a TDU war, that function can not solve this
problem.

ME:While it only takes one NN to support 8265 to detect the error and notify
ME:the operator, the damage is almost certainly already done before that one NN
ME:finds out about the duplicate names.  By the time the operator finds out
ME:about the problem he has to either

ME: -    disconnect the duplicate NN and rename it, or

ME: -    rename the VRN on every node connected to it.

ME:The net is that the proposed solution results in a TDU war, unless the first
ME:node that learns about the duplicate names is up-level.  The alternate
ME:solution results in a TDU war unless the duplicate network node is up-level.
ME: There doesn't seem much to choose between the proposals in a network with
ME:both up-level and down-level NNs!

Yep, that's what the operator needs to do.  Regarding the TDU war discussion
I've already answered that.

ME:As I pointed out above, there is little to choose from a migration
ME:standpoint between the the original proposal and what we are suggesting -

I have to disagree with this statement.  The solution to maintain a separate
node entry for the duplicates simply does not migrate.  If a duplicate real
NN enters the network, back-level NNs will overwrite the VRN's node entry,
and put the TG records owned by both the real NN and the VRN under the same
entry, which causes routes to be built that will fail during BIND time.
If the duplicate NN is itself back-level, it will mark all of the VRN's TG
records as inconsistent.  This solution addresses none of these problems.

The solution described in 8265 does have migration hooks.  If an
up-level NN is connected to the duplicate NN, it will bring down its CP-CP
session with that node, thus preventing the duplicate from broadcasting TDUs
marking the VRN's TG records inconsistent.  So, even if down-level NNs do
exist in the network, they won't mess with the VRN's information in their TDBs
because they won't learn about the duplicate.

An Alert is also generated whenever one NN detects this error.  So the
operator knows that duplicates exist, and can fix the problem via the
manual configuration Mike described in a previous comment.  Yes, requires
extra work, but it does completely correct the problems I described 2
paragraphs back.

In no way should a TDU war ever occur in this case.  An NN should not
argue about TG records owned by a VRN, even if that NN is the partner for that
TG record.

ME:ie. neither solution works seamlessly if not all NNs are upgraded.
ME: Therefore, unless there is another approach which does migrate seamlessly,
ME: we should be choosing the best long term solution.

ME:It is utterly reasonable to allow NNs and VRNs to have the same name, since

ME: -    the architecture has obviously been designed to make sure that it is
ME:     always possible to distinguish between an NN and a VRN (and it is
ME:therefore
ME:     technically feasible)

ME: -    it otherwises appears to be a fairly arbitrary restriction to the
ME:average
ME:     'dumb' user.

You seem offended by my 'dopey' remark in my previous note.  I apologize.  I
meant the comment to be facetious rather than to be taken literally.  It's my
attempt at making these technical discussions a little less dry for the
average member of this mailing list.  I've done enough dopey things in my
life to write a book about (and someone probably will), so I'm not one to talk.

ME:For the above reasons we strongly recommend the alternate solution we
ME:suggested is used as the basis for solving this problem.

And I think the alternate solution is dopey (just kidding :)).  Actually, I'd
prefer your solution if there was a simple way to prevent back-level NNs from
mucking up their TDBs.  You can't just ignore that fact in any solution
addressing this problem.

OK...we obviously reached an impasse here.  I'd like to hear from other members
I promise to keep my e-mouth shut for the rest of this discussion, and
let you and the rest of our members decide how we should solve this problem.

Regarding 8266:

Concerning your comments, I agree with everything you stated with one minor
exception.  Using the Add(ALL) option and then the Delete(name of EN) step
shouldn't cause failures.  It's true the description for this item doesn't
explicitly state how to do this, but it's fairly simple for SS to maintain
a COS-authorized list if the user initially states that he/she wishes to
restrict all ENs from using their own COS.  The COS-authorized list contains
the exceptions to the rule (no EN can use its own COS).  I regarded this
as an internal function, therefore saw no need to architect it.

OK, how do other people feel about just adding a parameter to the START_NODE
command rather than using a new NOF command?  One thing to consider with
the START_NODE is that every time you wish to add or remove an EN from the
COS-Restriction list, you now need to restart the node, rather than being
able to modify the list without bringing the node down.  Also, for
many links the local NN doesn't even know the name of its
adjacent node until XID time (which may be too late for the START_NODE
command?), so I believe that the START_NODE parameter and the DEFINE_CLIENT_
RESTRICTION command are not so similar.

Again, it's time for you and the rest of the AIW members to decide on the
best solution.

Regards,
Tim

---

From: [email-masked] (Dave Finnie)
Date: Mon, 31 Jul 1995 10:34:50 +1000

8265
----

While I agree that in hindsight, perhaps the safest solution would
be to have two separate name spaces - one for real NNs and one for
VRNs, I have to agree with Tim that this could cause some major
problems in the network.

The proposed solution does not solve the EN issue, and I think that
is a bit of a problem. I always thought that an architecture should
be as bullet proof as possible, and it obviously isn't as it stands.

8266
----

I agree that it makes more sense to put this on START_NODE than creating
a new command, and I also agree that there is a problem in changing the
configuration (restart of node). Our product implements what could be
termed an ALTER_NODE command (in fact we allow ALTERs of all resources).
Perhaps this is a co-solution that would overcome this deficiency in
START_NODE ?

Dave

---

From: Robert Clouston <[email-masked]>
Date: Mon, 31 Jul 95 8:28:13 EDT

8265
----

I think the separate namespace could be applied to EN TG vectors only, to
solve the problem of ENs knowing a name as a VRN while the NNs know it
as a real NN.

When the origin NN server looks at the origin and dest TG vectors, it
checks the node type in the TDB against the VRN indicator in the CV4680
before adding the node as a tree root or a potential destination.
This would keep a route from being falsely calculated through a real NN.

At the end of route calculation logic already exists to check
for a common connection by both ENs to a VRN that the NN server does not
know about. It might take a small change for the NN to recognize that
it doesn't know about this VRN when it may have a real NN by the same name.
I don't have access to the APPN code anymore so I am going from memory and
the APPN reference on this.

This should fix the EN problem without separated in the namespace in
TDU processing, which would break many existing implementations.

Bob

---

From: "jim (j.) cobban" <[email-masked]>
Date: Mon, 31 Jul 1995 14:34:00 -0400

>Perhaps this is a co-solution that would overcome this deficiency in

Any time I have raised concerns about the NOF interface definition it has
been pointed out that it is not really part of the external behavior of APPN.
That is because the NOF would always manifest itself through some platform
specific operator interface.  The only partial exception to this would be
the APPN MIB.  So the question of whether this feature is defined through a
START_NODE parameter, or through an ALTER_NODE command, or through a
DEFINE_CLIENT_NODE_RESTRICTION  command, is not really an architectural
consideration.  The APPN MIB is read-only, so that also has little impact
on the implementation except that at some point we must agree on how the COS
restriction list will be visible through the MIB.

I therefore propose that the scope of this proposed amendment be restricted
to a description of the change in the behavior of the node, particularly as
it is manifested externally.  The NOF interface definition is not an external
interface of the APPN node, and in fact is not implemented exactly
as specified in the architecture by ANY conforming implementation of APPN.

The first item which therefore changes is the title of the feature by
removing the first 4 words.  The reference to the NOF command is removed from
the abstract:  The second sentence could become "It describes a new option to
allow a network node to assign ..."

The description of DEFINE_CLIENT_NODE_RESTRICTION is removed from pages
3-15,16,55,56.  It is not necessary for the architecture to define how the
node is configured to implement this option.  Also removed is the description
of the RESTRICT_COS signal from NOF to SS on page 3-95.

The discussion in Session Services should describe the behavior, and not the
implementation in terms of a RESTRICT_COS signal.  The specific changes to
page 5-39 include:

  - remove the phrase ", through the NOF signal RESTRICT_COS" from the first
    paragraph.
  - the second paragraph should discuss the restriction list without
    detailing how it is implemented.  For example:

    "SS maintains a list of the CP names of client nodes which are restricted
    in that any COS name which they supply on a session initiation request
    will be ignored.  This table may indicate that all client nodes are
    restricted."

  - the third paragraph is removed entirely.

The proposed changes to figure 5-7 and the following text on pages 5-52
through 5-54 is removed.

The remaining changed pages only describe the impact on external session
initiations, so they are fine by me.

---

From: Mike Evans <[email-masked]>
Date: Wed, 02 Aug 95 11:05:00 BST

Tim

I agree that our ramblings were getting a bit cryptic (and no you didn't 
miss any open issues).

I'm going to be on vacation for much of the next couple of weeks, and it 
seems we are still some way from coming to a conclusion on both 8265 and 
8266.  I suggest we schedule some time during the architecture reference SIG 
at the upcoming AIW to attempt to resolve both issues.  What do you think?

I'm also likely to miss the Tuesday sessions, so it would be good if we 
could schedule this for the Wednesday.

Mike